Businesses or other entities engaged in software product deployment are faced with the risk of Deployment Failures (DFs).
DFs may include Post-Production Defects (PPDs) and Failed End-User Interactions at various levels, including the project and release levels. Failed End-User Interactions may also be called Failed Customer Interactions (FCIs).
The likelihood of a DF is affected by a number of factors, including other DFs earlier in the production chain.
For instance, a high level of design complexity in a project as conceived might lead to the late submission of a requirements document (an earlY-stage DF). The late requirements document would then increase the likelihood of a later-stage DF such as a failure to adequately test. The failure to adequately test might then increase the likelihood of an even later stage DF, such as an FCI.
For the purposes of this application, a lower level failure state is a Root Cause (RC). An Intermediate point of failure resulting from one or more Root Causes is a Minor Effect (ME). An end-state failure mode resulting from one or more Root Causes and/or Minor Effects is a Top Event. A Top Event may also be referred to as a Primary Effect.
In the example given immediately above, for instance, the high level of design complexity is a Root Cause, the failure to adequately test is a Minor Effect, and the FCI is a Primary Effect.
Similarly, a physical environment defect may be a Root Cause which might increase the likelihood of a failed change error (Minor Effect), which could in turn increase the likelihood of the FCI (Primary Effect).
A Minor Effect may simply be a conceptual label for two or more Root Causes and the relationship between those Root Causes. A Minor Effect that can be independently measured may be treated as Root Causes.
Entities benefit from anticipating the risk of Deployment Failures at every stage by allowing the prediction of such issues early enough in the development lifecycle such that mitigating actions can be taken and any negative end-user impact can be limited.
Conventionally, DF risk assessment is established by subjective opinion, usually by an individual with some experience in the field. Such subjective analyses are, however, unreliable and the mechanism for making such analyses is difficult to teach or share.
Further, the subjective analyses are not readily scalable. That is, undertaking such subjective analyses in connection with more than one development project may often require the expertise of different individuals having particularized expertise
Also, conventional DF risk assessment is generally at least partially retrospective, undertaken at the earliest only after Root Causes have aggregated to the level of Minor Effects.
The conventional method generally allows for accurate DF risk assessment only at later stages in the deployment process, such as late-stage testing, which may be after the most efficient opportunities to mitigate have passed.
Businesses or other entities often attempt to model or analyze failure processes of various systems.
One mechanism for engaging in such modeling is the process of Fault Tree Analysis (FTA).
FTA may be composed of logic diagrams that display the state of the system and it may be constructed using graphical design techniques.
In an FTA, an undesired effect may be taken as the “Top Event” of a tree of logic. Then, each situation that could cause that effect is added to the tree as a series of logic expressions.
Events for which no cause is recognized in the fault tree may be termed Base Events, and events within the fault tree that are neither Base Events or the Top Event may be termed Intermediate Events.
Conventionally, fault tree analysis comprehends the combination of Base Events and Intermediate Events as Boolean or probabilistic structures.
That is to say, as a descriptive matter, a fault tree may conceptualize the occurrence or failure of some event as related to the occurrence or failure of some set of other events in Boolean terms: Event A will occur if Event B AND Event C occur OR if Event D occurs.
As a predictive matter, a fault tree may conceptualize the probability of the occurrence or failure of some event as related to the probability of the occurrence or failure of some set of other events in probabilistic terms: The probability of Event A occurring is determined by the mathematical evaluation of probability of Events B and C occurring OR the probability of Event D occurring.
The Boolean, descriptive analysis can be understood as a special case of the probabilistic analysis, where the probabilities are either 100% (True) or 0% (False).
Such Boolean/probabilistic combinations can be readily understood under mechanisms of algorithmic conversion well known to practitioners. For instance, in the example given, where the probability of Event X is designated P(x), then P(a)=(P(b)*P(c))+P(d).
Conventionally fault trees may further include the assignment of weights to particular events, such that certain events are given more significance in the algorithm by the addition of a weight multiplier.
In some circumstances, however, the application of conventional Boolean relationship algorithms and weighting to the fault tree structure is insufficient to adequately describe or predict the relationships between Base Events, Intermediate Events, and the Top Event.
Moreover, in some circumstances the application of conventional relationship algorithms and weighting requires unwieldy and very complex fault tree structures to maintain the integrity of the representational aspect of the fault tree.
It would be desirable, therefore, to provide a method or system for making less subjective DF risk assessments.
It would also be desirable, therefore, to provide a method or system for describing the relationships between Base Events, Intermediate Events, and the Top Event of a fault tree more adequate to a comprehensive representation and allowing for a less complex fault tree which nonetheless maintains the integrity of the representation.